Night Owl 6/Night Owl's Shareware - PDSI-006 - Night Owl Corp (1990).iso/034a/xrs45dox.zip/NEWIN450.DOC

Text File | 1991-05-31 | 33KB | 519 lines

Changes from XRS v 4.10 -=> v 4.50 Release


[This version contains 107 changes/updates/fixes condensed below:]


1) Support for .QWK format mailbags is integrated into the program by
 calling portions of Rudi Kusters' "XCS" (eXpress Conversion System).
 Picking a .QWK format mail bundle will cause XRS to first unpack it,
 then call QWK2XRS to convert the bundle to an XRS mailbag.  Upon exit,
 XRS will call the "Bundler xxxx" program, or "XRS2REP.EXE" if none is
 specified.  (These two programs are part of Rudi's XCS version 1.00 or
 later.  XCS also includes programs to transport to and from VAX/VMS
 Mail, FidoNet *.PKT mail packets, archived messages, etc.)  XRS does
 not assume .QWK format mail bundles are the same 'flavor' packer you
 have for your .?XR format (XRS mailbags), or assumes "Zip" if you have
 QWK mail only.  Instead, it 'smells' them to determine unpacker.  For
 .QWK format mail, XRS limits the subject field to 25 characters, and
 adjusts the on-screen box.  Note that this window scrolls if you put
 more characters in than fit in the window - the length of the prompt
 is dependant upon which native language you use (so in some cases it
 may not scroll at all).  XRS recognizes "PCRelay:" as an origin line.
 (the current version of XCS at XRS 4.50 release time was "XCS100.ZIP")

2) The file input and output filters have been changed.  Basically, I've
 decided to leave it up to the SysOps and users to decide what is proper
 in mail depending upon their network, etc.  Because it is possible to
 compromise FidoNet security and/or deliberately send naught things (the
 ANSI sequences starting with <ESC> could reprogram your keyboard for
 you), there are still a very few limitations (filters) as follows:
   On the input side, <TAB> characters are expanded to spaces (dependant
 upon the setting of the "Tab x" setting - default is 8), <NULL>, <ESC>
 and <EOF> characters are stripped, and <CR><LF> pairs are translated to
 <CR> only so they display correctly on-screen. (this filter is the one
 used when you "Import" a file either with <ALT_F4> when in the internal
 editor, and in response to the "Insert from another file?" prompt.
   On the output side (writing messages from the internal or external
 editors), <CR> characters are translated back to <CR><LF> pairs so the
 file will print correctly if you wish, <NULL>, <ESC> & <EOF> characters
 are stripped.
   Note that the internal "CopyMailToPkt()" function (for FidoNet export
 to *.PKT file format) converts <CR><LF> pairs back to <CR>, but does
 not strip <LF> unless it is preceeded by <CR>, and also strips <NULL>,
 <ESC>, <EOF> and <DEL> (0xff).  If you use an external mail converting
 packer (such as Rudi Kusters' XRS2REP.EXE .QWK format packer program),
 different rules may apply according to the currently prevailing rules
 and regulations of the other nets.
   Actually, it is physically impossible to enter an <ESC> or <NULL> in
 any message using my internal editor, since <NULL> signals the end of
 the editor buffer, and an <ESC> character would not place in escape in
 the message, but rather pop up the "Save Message?" selection window.
   Before anyone takes off on a snit about eliminating <ESC> (because it
 is "required" for ANSI color sequences), two things: as I noted, those
 same sequences could be used by a malicious person to reprogam your own
 keyboard very easily, so <Enter> produced "Echo Y | Del *.*" or even
 worse, "Echo Y | Format c:" or something like that.  Also, there are
 several different methods including the one already implemented by Mark
 Herring in QMail², for example (which do not require using an <ESC> and
 cannot be used to wreak havoc on other users).  If there are enough
 people that want it, I will consider putting an "ANSI_Art" routine into
 future versions of XRS, although they are truly a waste of bandwidth!
   In doing this, I also found the bug that caused formerly "illegal" (in
 FidoNet) characters to import as the beta 'ß' symbol and also a bug that
 made portions of lines after "illegal" symbols to disappear when you had
 them in quotes, and fixed both.

3) Complete and full-functional "threading" is available.  If you put the
 new "Threading" parameter in your CONFIG.XRS file, the plus and minus keys
 become thread following if (and only if) a thread exists and it is in the
 mailbag, instead of duplicating "Next" and "Back" respectively.  If there
 is a previous or next message in a thread and the message is in the open
 mailbag, the "<" or ">" next to "Thread" in the header will be replaced by
 a flashing "<<" or ">>" and if you have threading turned on the plus and/or
 minus keys are redefined to read the previous and/or next message in the
 thread as applicable (if there is only a back-thread, "+" still reads the
 next message, and vice-versa).  The change is indicated by "bottom-line"
 help screens as the menu-bar is scrolled.  The blinking double chevron
 pointing in either direction indicates whether the threaded message is in
 the mailbag or not - whether the plus and minus keys have their threading
 function turned on is completely independent.  Threading works by creating
 a doubly-linked list from the single "ReferTo" previous message thread
 pointer in each MAIL?IDX.XRS record which is 'cleansed' of messages not in
 the mailbag, cross-links or circular links are removed and then everything
 left is reverse linked to provide forward pointers.  If this information
 is inaccurate or missing, threading will provide poor results at best - if
 any.  Note that some previous versions of XRS had zeroed out the "ReferTo"
 field when saving progress because no valid pointers were found - these
 old mailbags will not thread properly (XRS now saves only valid pointers,
 discarding any to messages outside the range of messages in the mailbag).
 Another thing you should note: Threading _completely_ ignores any of the
 "filters", like "New Only" or "To You" and displays the threaded message.
 Since the "previous" thread link is saved as part of MAILxIDX.XRS, each
 mailbag only has to be 'cleansed' and doubly linked once (this is why the
 total link count = used link count each time thereafter).  <F4> hot-keyed
 configuration changing threading on-the-fly is instantaneous - if you see
 an inactive (non-blinking) thread, and want to follow it, simply turn on
 threading from the <F4> menu and the thread link will become active (and
 you can turn it off similarly, as well - when you toggle that option, any
 onscreen chevrons will either begin to blink indicating they are "hot" or
 quit blinking, indicating they are available but inactive.  Of course, it
 is easiest just to leave threading on all the time and use the <Enter> or
 "<N>ext" and "<B>ack" for normal reading and "+"/"-" for threaded reads.
 Messages which are read following threads and 'backed out of' are marked
 read and not redisplayed later in the mailbag.  (once menubar is built,
 the "help" descriptions will not change if you toggle threading.)  To
 facilitate 'true theading', the plus and minus keys can be locked out
 when there is no thread to follow, allowing easier thread following.
 Put "Thread Only" in CONFIG.XRS to activate this function.  Thread only
 implies "Threading".  The <F4> configuration "Threading" option is a
 'tri-state' button, alternating between "Threading Off", "Threading On"
 and "Thread Only".  For each line in the "<J>ump" list that has active
 back or next thread pointers, chevrons to the left and/or right are shown
 in front of "Re:".  If you use "Page Mode" viewing, and the "N = Next..."
 is displayed in between pages, "+" and "-" skip to the previous and next
 message without regard to the "threading" mode being used.  "<H>ome" is
 added to the menubar if a previous thread is active, so you can return to
 the 'top' of a thread instantly and proceed to read the next topic.

4) Mailbags may have an unlimited number of messages, however you *must*
 have LIM/EMS memory if you want to preload the summary and have mailbags
 with more than 2000 messages!  The number of messages in an area is not
 limited.  (Preloading the summary file for 5000 messages requires 13
 32k blocks of LIM/EMS, for example.)  Using indirection this version
 defines, allocates and loads the tables at run-time, taking less memory
 than previous versions to load (by more than 20k), but expanding the heap
 as is needed to accomodate larger mailbags.  Actually, mailbag size is
 limited only by disk space and available RAM.  You must have enough free
 "low" RAM to load the MAIL?IDX.XRS file plus 16% (see above - XRS now
 build doubly-linked threaded topic lists) - 14 bytes per message in the
 mailbag.  The max is probably somewhere around 30,000 realistically...
 NOTE!! Having more than 1200 messages requires you to either A) turn off
 "Preload Summary", B) use an overlayed version of the program, C) have
 the required amount of LIM/EMS to preload the summary index or D) have a
 386 or 486 machine with memory manager leaving 600k or more free RAM when
 starting XRS.  XRS has no limit on the number of messages in an area,
 however more than 1000 messages per area will create an extremely large
 "<J>ump" list which requires a correspondingly larger amount of free RAM.
 MS/DOS 5.0 with DOS=HIGH or DR/DOS 5 will help considerably!  Using the
 "VidRam" program that comes with QEMM also adds 64k "low RAM" that DOS
 can see.  (but see below - it is possible to "virtualize" jump lists to
 force them to use a fixed amount of memory, "paging" elements in and out
 of the list as you scroll thru it)  With more than 1600 messages, unless
 you turn "Preload Summary" off, you probably need some combination of or
 "all the above".  XRS uses a "Heap Expander" routine to store portions of
 dynamically allocated RAM in LIM/EMS memory if there is any available,
 otherwise the memory from the DOS far heap (lower 640k) is used.  "Preload
 Summary" uses from one to 32 blocks - 64k max each, eliminating all of the
 summary from a mailbag from the far heap (storing it in blocks of LIM/EMS
 instead).  Even if you don't have LIM/EMS memory this version is much more
 efficient with the dynamically allocated RAM due to optimization of the
 heap routines with a 'best fit' algorithm (20 to 30% less memory is
 required to store the summary).  A nice side-effect of this is that if the
 "Preload Summary" is stored in LIM/EMS - that formerly 32K to 160K of RAM
 is not swapped out using the <F10> shell to DOS hotkey.  Also, another
 side-effect: preloading summary takes about half as much time.
 "SET HX=/NOEMM" disables the "Heap Extender" routines from even trying to
 use LIM/EMS memory.  "No EMS" in the CONFIG.XRS file forces "SET HX=/NOEMM"
 also. (you don't have to do both to totally disable LIM/EMS access, but you
 can only disable HX if you want, but using "SET").  After "Preload Summary",
 if any LIM/EMS memory was used, the amount is shown along with "low RAM"
 in the memory allocation usage message.

5) XRS supports up to 1024 conference areas selected from 65535.

6) XRS virtualizes the "<J>ump" list if more than 500 messages would be
 in the list.  Any number of messages can be displayed since I virtually
 page list elements in and out (in 50-message units) as you scroll around
 the list.  Note that this makes the initial "huge" lists pop-up much
 quicker, and the paging does not noticably slow the list scrolling, so
 the net effect is that everything is faster handling the larger lists
 instead of slower.  In order to be most flexible, you can specify the
 threshold for virtualization of the list (which defaults to 500) to any
 number in the range 100 up to 3000.  XRS builds any "<J>ump" list with
 fewer entries normally, but builds a virtual list for larger lists.  If
 you run under DesqView, setting this to a low number will allow you to
 read 5000+ message mailbags in as little as 300k.  If you have plenty of
 free RAM, increasing it may provide better performance on large lists.
 Each time scrolling the virtual list causes paging, XRS will swap out
 up to 20% of the list (under normal circumstances that would be 100
 messages) so having a very small number will give good response and use
 little memory but require more frequent disk accesses, while using a
 large number will eat more free RAM, but provide generally smoother
 operation and less frequent disk accesses.  To set the threshold for
 "<J>ump" list virtualization, use "Virtualize xxxx" in your CONFIG.XRS
 where 'xxxx' can be anything within the range 100 to 3000 - anything
 outside that range will be adjusted.  Of course, if you have "Preload
 Summary" on, disk accesses are not required in either case (since the
 entire list is either in LIM/EMS or "low" memory).  <CTRL_PAGEUP> and
 <CTRL_PAGEDOWN> take you to the current (not virtual) list top element
 and bottom element respectively (you still have to use PAGEUP/PAGEDOWN
 or UP/DOWN arrows to get into any other virtual segment of the list).
 Also, "VirtualJump xxx" allows you to adjust the default number of list
 elements which are deleted from one end of the list and an equivalent
 number appended to the other end of the list.  The default is 50 or
 the number of lines per page, whichever is less.  Adjusting these two
 parameters allows you a full range of virtual list control - under DV
 you could limit "Virtualize 100", "Virtualimit 38" (assuming 25-lines)
 and make it run in minimal (less than 12k) dynamic RAM as opposed to
 the former unlimited amount proportional to the entire list size.  You
 can also minimize virtual "waits" by increasing the "Virtualize xxxx"
 as high as you can if you normally read mailbags larger than 1000 or
 more messages, and adjusting "VirtualJump xxx" can either quicken the
 response (larger size) minimizing waits, but longer waits each time,
 or slow it down somewhat by requiring smaller, more frequent paging.
 The default settings I use are best for 'normal' users, the optimal
 settings for your computer depend upon many things - processor power
 and hard disk access time, mostly.  You may have to adjust these to
 find your "prefered" settings.  Note that the up and down arrows on
 the scroll bars blink if they are 'virtual' links and not physically
 in the current list, but function the same in all cases.  Also note
 that using "PAGEUP or PAGEDOWN" you can jump into a virtual segment
 even though the arrow is not blinking (since jumping a page would put
 you outside the current physical list).  Now that you're all lost, I
 suggest you just try it, it all comes naturally, just like before,
 except you will see "Please Wait" during virtual paging of the list.
 Successive <PAGEUP>, <PAGEDOWN>, or up/down arrows with the mouse will
 continuously page in new elements of the virtual list until you reach
 either end.  I think the number of message when the "To You" filter is
 on (which would require more code to implement) is normally going to
 be low even if you have a very large mailbag, so if the "ToYou" filter
 is on, no virtualization is done (to keep the code-overhead down).  If
 you build a huge mailbag with mostly/only messages "to you", XRS will
 take 10k RAM per 100 messages to display lists of "To You" elements
 (although simply turning off the "To You" filter from the <F4> config
 menu forces XRS to virtualize the list anyway!).  Since virtualizing
 the list requires more frequent access to the SUMMARYx.XRS file (or the
 data preloaded in LIM/EMS or "low" RAM), and very large lists are now
 possible, by default I automatically bisect the list 16 ways and record
 either the offset into SUMMARYx.XRS or the HeapXtender handle and HX
 offsets.  This allows very fast paging of new items into the list.  If
 XRS detects more than 1000 messages, it will increase the number of
 list pointers by 16 every 1000 messages, up to 128 total, so that no new
 insertion point is ever more than 63 messages from the closest pointer
 (unless you have a mailbag with more than 8000 messages!).

7) I no longer use a "COUNTRY=xx"-dependent routine to get a spelled-out
 month for the date string in messages, since depending upon which code
 page you use, and which country code you used, you could get either your
 own (i.e. native language spelled months) or garbage before.  You should
 always get consistent dates in message headers  (and they should always
 be the English "short" three-letter spelling of the month), but all of
 the on-screen clocks should still use the 'local' format.

8) If XRS finds the "$$ACTIVE.XRS" semaphore file at startup (which is
 normally an indication that the program is already running), it will let
 you bypass that check and start anyway by answering "Y" to the "Continue
 Anyway? (y/N)" prompt - the default is "N".

9) If you hit <ESC> when the message reading menubar is displayed, you
 go back to the main menu instead of proceeding to the next message.
 This eliminates the need for the "<E>xit" option, which gives a little
 more room on the menubar for foreign language versions.

10) If the "Read Only New" filter is turned off when you exit, XRS will
 assume you have read all messages and offer to compress and/or delete
 the current mailbag (or leave it alone).  If you compress it, you may
 optionally select a different name for the output file.  You may pick
 the default action for the above using a new CONFIG.XRS parameter
 "EmptyBag x" where 'x' = the hot-key for any of the four menu selections
 (in English they are "<C>ompress Mailbag", "<D>elete Mailbag", "<R>epack
 AND Delete" and "<L>eave it Alone" - so C, D, R & L are valid).  If you
 don't preselect one, the default is "Leave it Alone".  If you use a
 non-English binary FNLS file ("Foreign Native Language Support - it is
 named XRS$ALL.DTA just like the English version shipped with XRS), those
 options will be different, depending upon which four "hot-key" options
 are on your native language's menu.  By default, mailbags which are
 recompressed go to the "InDir xxxxxx" subdirectory (where they started)
 or if none exists, into the current subdirectory.  If you want to use a
 different "holding area" for read mailbags, use "SaveBagPath xxxxxx" where
 'xxxxx' is a subdirectory.  XRS automatically fiddles with the output
 filename if the one it comes up with using "BAG_ID.XRS" and the packer
 already exists, so you do not end up with more than one mailbag inside one
 archive or accidentally overwrite an old one.  The "Packer xxxx" is used,
 and if none is specified, PKZip is used.  Note that mailbags which were
 originally QWK format are stored in .ZXR format.  The routine I used will
 allow you to store over 100 mailbags for each BBS before you have to move
 and/or delete some - be careful!  (this could easily eat up all of your
 available disk space in a hurry...)  If you "Compress" or "Repack/Delete"
 a mailbag that has not been fully read, even if you have a "SaveBagPath
 xxxx" defined in your CONFIG.XRS parameter file, it will go back into the
 "Indir xxxx" path instead.  This way you can still put them away partially
 unread, open a new mailbag and read, then go back to them, while XRS will
 still store completely read mailbags elsewhere (without you having to move
 the file(s) around if you use "SaveBagPath xxxx").  You can force this
 option to be displayed by using "Always".  If there are remaining unread
 messages, a warning banner and a different "Bottom Line Help" is displayed.
 Also, if you have unread messages on exit and the "Compress/Repack&Delete/
 Delete/Leave" menu is displayed, the default is always "Leave" mailbag.
 If the user sets "Emptybag x" to an invalid value, an error message is
 displayed.  XRS will now notice that and chose the "Leave" option as the
 default.  Note that as always, XRS will automatically adjust to a foreign-
 language binary overlay and use the letters which correspond to that native
 language's menu hot-key selections.  If you use a non-English overlay, your
 parameters must specify valid keys for your native language instead!

11) The <F2> screen is now the "Status" screen.  It now contains several
 new bits of information, including NDP (math coprocessor), etc.  Since
 noone knew what "RelativeSpeed" meant (it was based on PC/XT = 10 units),
 I changed it to "RelativePower xx.x" where 'xx.x' is the power relative to
 a 4.77MHz 8088 processor.  The status window no longer displays a random
 string in front of "286?" if it cannot identify your processor.  (every CPU
 that was "out of range" of the normal detection routines has been a 286.)
 XRS 'knows' when QEMM/386 memory manager is in use and displays QEMM
 instead of YES for "VM86" mode in the <F2> status window if it is found.

12) XRS names all the LIM/EMS handles it uses so you can tell how each
 piece is being used (includes overlay cache, HeapXtender and swapping).
 You can see LIM/EMS handles with "Mem/d" (DOS 4.0+) or MFT, etc.  Names
 are "XRSCACHE" for overlayed versions if you have 96k LIM/EMS memory at
 run-time, "XRS$HXxx" where 'xx' = '00'..'31' for LIM/EMS handles used by
 the HX routines, and "XRS$SWAP" for the swapfile for shell to DOS, etc.

13) XRS saves and restores the video mode no matter what it is when you
 start, even if you tell it not to adjust the video mode.  It also resets
 that mode upon return from external program calls, since it is possible
 that they have changed the lines-per-screen size.  The only potential
 screwup is that if you drop to DOS and do something that changes your
 *hardware* font, without changing the video mode, then XRS has no way of
 knowing you have changed lines-per-screen (therefore, if you do that,
 the only way you can 'fix' it is to return to DOS and reload the correct
 hardware font).  This should eliminate certain combinations of external
 programs which are not "screen-smart" from messing up the display (it
 usually shows up as random "junk" characters (with random attributes)
 in the bottom few lines of the screen.

14) You can have XRS automatically sort the <J>ump lists by subject with
 a new CONFIG.XRS parameter "Sort Subjects".  This takes slightly longer
 than displaying the list unsorted, of course.  Used in conjunction with
 the new threading support, this allows <J>ump lists to be sorted by
 thread or 'topic' as well.  This can also be turned on and off from the
 <F4> hot-keyed configuration window, allowing you to only sort the list
 when needed.  Several hot-keys were changed (in the English overlay,
 anyway) to allow using the first character of each message (as hot-key).

15) XRS does "relative jumps" on the BATxMAIL.XRS file rather than seeks
 from the beginning of the file.  I compute the difference from current
 file pointer to where I want to go and do a relative jump (seek).  This
 speeds displays of headers during <J>ump by a factor of two, and even
 more dramatically speeds things up if you have the new "Sort Subjects"
 parameter in effect.  This also makes threaded reads and reads inside
 areas or "to you" filters much faster, since each time the file pointer
 is moved the average distance moved is smaller (typically much smaller).

16) "Hide Search" is only effective for "AutoTag/Search" modes.  You can
 easily take your pick during manual searches.  "N)onstop" in the <F8>
 search/mark/tag routine is now "H)ide", which does the same thing as
 before, except output isn't shown on the screen.  This allows you to
 hide non-automatic searches if you wish, as well.

17) "Page View" mode colors work exactly as the list view mode, and it is
 79 characters wide with no blank space down the left side, allowing one
 more character to show (which formerly got whacked on rare occasions).
 The scrollbar arrows work differently - mousing them once moves one line
 but holding down the button repeats at a rapid rate, the 'arrows' are
 'pointers' instead, to remind you it works differently.  The action of
 the "Up", "Down", "PgUp" and "PgDown" keys and mouse up/down arrows are
 similar to Vern Buerg's "LIST.COM" program.  You can vary the scrolling
 rate when using the mouse (held down) to anywhere from 1 to 20 lines per
 second (the default is 6/sec. which works well) by using a CONFIG.XRS
 parameter "SkipRate xx" where 'xx' = 1 to 20.  ("No Mark" in CONFIG.XRS
 file is obsolete due to this change!)

18) You can have a file of up to 256 random tag lines which are used if
 there is no conference-specific origin line specified in "XRS.ORG" or
 the "(bagid).ORG" file.  (and assuming there is no XORIGIN.XRS 'lock')
 The format is simply lines of up to 60 bytes in a text file.  If the
 text is too long to fit, it is truncated.  The filename "RANDOM.XRS"
 is searched for on the PATH if it is not found in the current directory.
 ('bagid' above = the mailbag name)

19) XRS no longer deletes "ACCESSx.XRS" when deleting old mailbags, so
 you can still send 'private' messages in appropriate conferences.

20) The <F6> summary window only shows the information preceeding the
 list of messages selected instead of the whole file (up to 65500 bytes).
 This allows the window to pop-up in much less RAM, and much faster if
 you have a large mailbag.  In order to see the entire list of messages,
 use <J>ump during "All Read Chronological".  I also find the 'marker' in
 SUMMARYx.XRS only once at the beginning of the program and thereafter
 seek directly to that location for <J>ump lists when preload summary is
 not being used (which makes jumping without preload quite a bit faster).

21) Overlayed versions now come in two pieces - the "stub" RESP_*.EXE
 plus a matching RESP_*.OVL file.  The resulting two separate files are
 20k smaller than the old combined into one *.EXE file method, since
 the very nature of RTLink+ allows the "stub" to be PKLite'd even though
 it is part of an overlayed program.  This also opens up the possibility
 of putting only the *.OVL file onto a RAM disk, or maybe placing the two
 files on separate floppy disks, etc.  The *.OVL file must be in either
 the same directory you run XRS from or available on your PATH (under DOS
 3.0+ it could be in the same sub-directory as the corresponding *.EXE).
 Because it is be possible to accidentally find the wrong corresponding
 RESP_*.OVL file, the RESP_*.EXE stub does a check to insure that the two
 are synchronized, and refuses to operate if it finds a "bad" overlay.
 It will display the exact name of the *.OVL file in the error message
 (you should delete the older *.OVL file and make sure XRS can find the
 new one, or use a newer *.EXE file depending upon which is older).  The
 overlayed versions require DOS 3.0 or higher for this to function.  One
 minor side-effect is you cannot rename the RESP_OVL or RESP_RTL files.

22) If you take out some "automatch" items from your CONFIG.XRS while you
 have a mailbag open, XRS 'remembers' that each message which was marked
 before is marked, but it no longer can find and color-cascade the items.
 XRS no longer 'skips out' forgetting to update the time in this case.

23) You can no longer pop-up the <F4> hot-keyed configuration window once
 you have entered the "exit procedure" (on the way out of the program).

24) The lookahead during "Optimize View" should be more accurate (it used
 to sometimes miscount how XRS would display a message, resulting in not
 putting a message in scroll mode or possibly cutting off the last line).

25) The "Quotometer" doesn't get confused it you exit from a message with
 the cursor at the end of the text buffer after cutting out quoted text.

26) If an empty "RESPONSE.XRS" files exists at exit, it is deleted.

27) XRS will look for both "XRSCOLOR.BIN", "XRS.ORG" and "XRS.KEY" on the
 PATH if they are not found in the current sub-directory.

28) Spurious bum addresses are not picked up - only "good" looking ones.
 (this is for netmail replies - XRS always tries to find the address in
 the message you are replying to, and occasionally made poor choices)

29) XRS uses up to four initials when quoting a message.  (this also
 means XRS needs to look forward 7 characters instead of 5 to tell if
 each line has already been quoted)

30) Things inside <> near the beginning of a line no longer throw XRS
 off. (making it think it is a previously quoted line when it is not)

31) If "No Alt Keys" is specified, <SHIFT_F5> simulates a <DEL> key.
 This was on <SHIFT_F3> (by mistake) before.  <SHIFT_F3> is the pop up
 window with registration information whether you have "No Alt Keys"
 or not (registered users do not normally see this screen at all).

32) Since .QWK style conferences usually end up with shorter braglines,
 the maximum size was increased to 60 characters (although usually only
 55 or so will fit).

33) I include separate Windows 3.0 <tm> .PIF files, one - RESPONSE.PIF is
 for non-386 mode use, and RESPONSE.386 (which should be renamed *.PIF)
 is for 386 "Enhanced" mode.  Both allow 100k XMS memory to be used, so
 if you are using an overlayed version, you can run with "cached" overlay
 segments while using less "low" memory.  I also include XR.DVP, a sample
 Desqview setup file - note that both of these *MUST* be inspected to see
 if they need adjusting for your environment (including the RESP*.EXE you
 use, if it is not RESPONSE.EXE!).

34) If you hit <ESC> for any of the "To/Subject/Address/Crash/Private"
 prompts you return to the next message if you are viewing messages or
 to the menu if you are creating a new message in "Create/Delete/Edit".

35) The mouse cursor doesn't get disabled "early" in certain situations.

36) XRS no longer depends on the messages numbers being in ascending
 sequence throughout the entire mailbag, so <J>ump works correctly if
 you have a mailbag from a BBS type which allows duplicate numbers in
 different conferences or if the messages are not sorted sequentially.

37) Changing (setting and resetting) the "Private" bit with <F3> on
 echomail areas (which allow them) works correctly.

38) Adjusting colors (via the <ALT_F7> hot-key) is no longer fatal on
 8088 or 8086 CPU chips.  I had some "'286" code hooked in there...

39) XRS uses "LHA.EXE" instead of "LHARC.EXE".  If you use .LZH files and
 don't have a copy of the new LHA (formerly "LHARC"), you should get it!
 The new version gives better compression and better performance.  (the
 current version is LHA210.EXE)

40) The overlay structure was hand-optimized again to further balance the
 size and mimimize intra-overlay calls.  This version still requires only
 96k of LIM/EMS (or XMS 2.0 extended) RAM to run at 100% the speed of the
 non-overlayed version (while using 80k less "low" memory).  The overlay
 caching works with less (or none), but swapping to disk will occur more
 often (increasing as the LIM/EMS or XMS available memory size decreases).
 This only affects RESP_OVL.EXE and RESP_RTL.EXE (the overlayed versions).

41) Matching of conference names is exact for *.ORG files.  (before, if a
 conference name matched the first portion of a tag line, it was used even
 if the whole name in the tag line was longer.

42) Internal changes to XRS require update to XCS version 0.47 since any
 earlier versions don't know how to handle mailbags with > 200 areas or
 more than 995 messages.  Because of this, XRS 4.11 refuses to work with
 a mailbag created by any earlier versions.

43) Handling of "out-of-memory" during display of the "<J>ump" list is
 improved.  Memory is correctly deallocated if you do not have enough RAM
 to display it and things should continue normally.

44) Exporting of "TAGged" messages is repaired.

45) XRS 'knows' about User Requests and automatically forces messages
 addressed to "XRS" into the LOCAL (Group #0) area marked as private.
 For information about User Requests (automatic file downloads and the
 ability to turn message areas on and off).  These are currently only
 supported by XRSDoor 1.44 or later. (RemoteAccess/Quick/SuperBBS door)
 Note that messages addressed to XRS have 'locked' attributes and can
 only be edited or deleted (the header cannot be modified).  See the
 separate file "REQUESTS.DOC" for detailed information on UserRequests!

46) Mailbags with non-standard characters in the last position of the
 file extension are found (i.e. "EBAYXCH1.ZX0" or "EBAYXCH1.QW0", etc).

47) "Force New" forces the "AutoMatch" and/or "AutoTag" parameters to be
 run but does not pop-up the summary/index window.  (mistakenly listed
 as "Force Auto" in the previous version's documentation - my fault!)

48) Exporting a message in "Quoted" format no longer sets the Reply flag.

49) "VerifyInsert()" displays itself on the same line as the other prompts
 during message header entry (i.e. subject, to name, etc).

and last, but not least:

50) Message display is faster in this version than 4.10! (more assembler)